排他制御とは、あるプログラムがその処理を実行している時、別のユーザの要求によって、他のプログラムの処理のなどのため、記憶装置の一部や他の外部装置へのアクセスなどが、混じり合わないように、処理の順序を管理するために、先に処理を開始したプログラムの処理を優先して実行する必要がある。並行して処理が実行されている銀行オンラインシステムでは、そのような複数のプログラムの処理で、共通する記憶域へのアクセスや同じハードウェア装置へのアクセスを先入れ先出しの順番で、実施する必要が発生する。

このようなプログラムの実行順序を管理するための方法として、それぞれのプログラムが互いに競合する記憶域や装置へのアクセスを開始する直前から、その記憶域や装置へのアクセスを完了し、他のプログラムの実行を許可できるところまで、他のプログラムの同じ記憶域へのアクセスや装置へのアクセスを禁止しなければならない。これを「排他制御」と呼ぶ。この排他制御のため、プログラムは、競合する可能性のある資源へのアクセスを開始する時点で、その資源へのアクセスを宣言し、他のプログラムのアクセスを禁止する。これを実行するのが、「ロック」と呼ばれている動作である。

ある資源があるプログラムによって「ロック」されると、他のプログラムは、同じ資源へのアクセスが禁止され、その場でプログラムの実行を待たされることになる。この実行待ちの状態は、「ロック」を宣言したプログラムがその資源に対するロックの解除を宣言する「アンロック」を宣言するまで、継続することとなる。つまり、各プログラムは、「ロック」を宣言して処理を行い、最後に「アンロック」を宣言して、他のプログラムによる資源へのアクセスを許可することが、原則となる。

そのような排他制御を行っているプログラムが実行されている途中に、問題が発生し、プログラムを異常終了させなければならない状況が発生することがある。この異常終了時に排他制御のロックを正しく解除してから処理を中断するように設計されていないと言う設計の誤りは、しばしば見られる問題である。異常終了について、それを予期し、最悪の事態を避ける設計がされていなかったのである。この問題は、本来であれば「設計レビュー」で分析され、解決策が議論されるべき問題である。レビューの実施が「おざなり」であったと言える。

設計のレビューでは、一般的に次の3種類の問題が発見される。その第一は、仕様の実現として正しいとは言えない設計で、「誤り」と呼ばれる種類のものである。その第二は、仕様に明確に記述されている問題や、「暗に仮定されている」問題に対する設計が記述されていないもので、「欠除(missing)」と呼ばれる種類のものである。そして最後は、仕様の記述に無い要素が、設計者の独断によって、設計に混入している問題で、「過剰(extra)」と呼ばれる種類のものである。日本人の技術者によるレビューでは、これらのうち、「誤り」以外の問題の指摘が極端に少ないことが分かっている。これは、専門技術者とは言え、設計レビューの訓練を受けていないことを端的に示している。

ロックが宣言された状態にある資源について、何かの理由でコンピュータ処理に異常が発見され、その資源に対する処理も異常終了をしなければならなくなった時、その資源に対する「アンロック」宣言をして、正常に処理を終わらせなければならないが、経験の浅い技術者は、その原則を忘れることがしばしばである。設計レビューでは、そのような「欠除」問題を想定して、しっかりとレビューするのが、技術者達に課せられた社会的使命である。それが疎かにされるのは、技術者達が専門家としての教育訓練をしっかりと受けていないからである。

大場　充著、「組込みソフトウェア工学ハンドブック」、日科技連出版(2014)